-
Notifications
You must be signed in to change notification settings - Fork 0
feature#44 search 검색 후 화면 개발 #46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
필터 open/close 여부에 따라 AnimatedVisibility 적용
공통 ProductCard를 통해 리스트 노출
- 중복 category name 기준으로 distinct 처리
- handleFilterClear() : 필터 초기화 및 검색 결과 재조회 - handleSubCategoryClick() : 서브카테고리 클릭 시 조회 - updateFilterProductCount() : 필터링된 상품 개수 계산 - updateFilteredProductList() : 필터링된 상품 리스트 - handleCategoryHeaderClick() : 상위 카테고리 클릭 이벤트 - initializeCategoryFilters() : 상위 카테고리 목록
- state, event 단일 전달 구조로 단순화 - 파라피터 문제 개선 및 유지보수 향상
if (subCategoryNames.isEmpty()) { | ||
return emptyList() // 선택된 필터가 없으면 빈 리스트 반환 | ||
} | ||
return getAll() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ProductDao 전반적으로 getAll() 를 사용해서 쿼리하고 있는데요. DB 쿼리에 파라메터로 넣지 않는 이유가 있으신가요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@f-lab-pepe @jaeho
단순하고 빠르게 기능을 구현하기 위해서 사용했던 것 같습니다. 멘토님의 코멘트를 생각해보다가 getAll()을 계속 사용하면 중복으로 조회가 발생하므로 불필요한 비용이 발생하는 것 같습니다. 현재 구조에서는 고정된 상품 리스트를 사용하고 있으므로 core모듈에서 공통으로 1번만 조회한 후 여러 모듈에서 재사용 하는 것이 성능면에서 최적화 될 것이라고 생각됩니다.
이렇게 진행하는 것이 괜찮은 방법일까요?
|
||
@Composable | ||
fun SearchResultScreen( | ||
viewModel: SearchViewModel = hiltViewModel(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hiltViewModel() 이건 불필요해보여요
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jaeho @f-lab-pepe
넵 해당 부분은 #48 리팩토링 하는 과정에서 제거 완료하였습니다!
- searchResultTab sealed class로 관리
- state, event 단일 전달 구조로 단순화 - 파라피터 문제 개선 및 유지보수 향상
- searchResultTab sealed class로 관리
추후 확장성을 위해여 public
…feature/feature#44_search
- 기존 모든 데이터를 가져와서 직접 필터링 (DB쿼리 X)
- DB쿼리를 통해 필터링
- 해당 카테고리 필터는 부모 카테고리 하위의 서브 카테고리가 있어 Impl에서 가공 진행
- CategoryEntity 구조에 맞춰 수정
- 기존 ProductDao에서 모든 상품을 가져와 필터링 - 수정 후, ProductsDao에서 상품 필터링
- 기존 ProductDao > 수정 후 ProductsDao
- ProductCount Method 제거 - 초기 상태에 가져올 필요없이, Product 조회 후 count 가져오기
🔖 요약
🛠 작업 내용
❗️ 참고 사항
|
🔖 요약
(SearchResultScreen, SearchResultScreenContent)
SearchFilterScreen
)🛠 작업 내용
AnimatedVisibility
사용하여 필터 컴포넌트 visibility 처리❗️ 참고 사항